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Abstract —  Robotic  tasks  are  becoming  increasingly  complex, 
and  with  this  also  the  robotic  systems.  This  requires  new  tools  to 
manage  this  complexity  and  to  orchestrate  the  systems  to  fulfill 
demanding  autonomous  tasks.  For  this  purpose,  we  developed 
a  new  graphical  tool  targeting  at  the  creation  and  execution 
of  robotic  tasks,  called  RAFCON.  These  tasks  are  described  in 
hierarchical  state  machines  supporting  concurrency.  A  formal 
notation  of  this  concept  is  given.  The  tool  provides  many 
debugging  mechanisms  and  a  GUI  with  a  graphical  editor, 
allowing  for  intuitive  visual  programming  and  fast  prototyping. 
The  application  of  RAFCON  for  an  autonomous  mobile  robot 
in  the  SpaceBotCamp  competition  has  already  proved  to  be 
successful. 

I.  Introduction 

Robotic  systems  are  growing  more  and  more  complex. 
Usually,  they  consist  of  a  heterogeneous  composition  of 
different  modules  for  specific  purposes  (manipulation,  vision, 
navigation,  etc.).  All  these  components  need  to  be  coordi¬ 
nated  both  in  terms  of  communication  and  task  flow.  ROS 
[1]  is  a  common  system  handling  the  communication.  Yet 
in  this  paper,  we  focus  on  managing  the  task  flow  (over 
time),  which  defines  the  flow  control  and  thus  orchestrates 
all  modules  of  a  robotic  system. 

One  approach  for  specifying  tasks  on  a  high  level  are 
symbolic  task  planners,  such  as  CRAM  [2].  On  the  one 
hand,  their  reasoning  system  and  access  to  world  knowledge 
databases  allow  for  complex  tasks  often  found  in  household 
scenarios  (e.  g.  setting  a  table).  On  the  other  hand,  these 
tools  haven’t  reached  a  level  in  which  they  can  be  applied 
for  specific  real-world  tasks,  especially  in  industries.  This  is 
partially  due  to  their  obligatory  (world)  model,  which  is  often 
either  under  or  over  constrained  and  fails  if  a  failure  during 
the  execution  cannot  be  represented  in  it  [3].  Moreover,  the 
demand  for  computational  resources  is  significantly  higher. 

As  an  alternative,  many  robotic  systems  use  approaches 
based  on  (hierarchical)  state  machines.  They  are  a  common 
way  of  defining  what  to  do  in  which  order  and  how  to  react  to 
certain  environmental  changes  or  events.  Here,  the  system  is 
typically  in  one  state,  from  which  it  can  proceed  to  a  defined 
number  of  other  states.  Which  one  is  chosen  at  run-time, 
depending  on  external  events  (like  sensor  inputs)  or  internal 
events  (like  the  result  of  a  successful  state  execution). 

Originally,  state  machines  have  been  programmed  tex- 
tually  as  code,  which  does  not  only  require  expertise  in 
programming  but  also  results  in  huge  code  fragments  for 
non-trivial  tasks.  Such  code  is  hard  to  maintain,  debug  and 
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Fig.  1.  Our  LRU  robot  [4]  at  the  SpaceBotCamp  2015:  Using  a  RAFCON 
state  machine  (lower-right  corner),  the  robot  automatically  grasps  the  blue 
container  for  rock  sample  before  returning  it  to  the  red  base  in  the 
background  for  assembly. 


understand.  Besides,  many  programming  languages  (such 
as  C[++])  are  compiled.  This  leads  to  tedious  development 
cycles,  as  for  every  change  in  the  program,  the  compiler  must 
be  run,  the  binaries  deployed  and  the  system  restarted. 

In  this  paper,  we  present  a  newly  developed  tool  called 
RAFCON  (RMC  advanced  flow  control ).  It  allows  for  visual 
programming  of  hierarchical  state  machines,  using  a  feature- 
rich  graphical  user  interface  (GUI).  It  is  programmed  in 
the  interpreted  language  Python,  which  relieves  one  from 
compiling  and  makes  it  possible  to  alter  a  state  machine, 
even  while  it  is  running.  Python  enables  the  integration  of 
heterogeneous  components  of  a  robotic  system  written  in 
different  languages.  The  novel  visualization  of  hierarchical 
state  machines  together  with  sophisticated  debugging  mecha¬ 
nisms  permit  fast  prototyping  and  intuitive  task  development 
with  closed  loop  system  tests,  without  the  need  of  deep  pro¬ 
gramming  skills.  The  architecture  enables  the  collaboration 
in  a  team  on  a  single  state  machine.  We  proved  this  in  the 
SpacebotCamp  20161,  in  which  RAFCON  was  used  for  the 
mission  control  (see  Fig.  1).  The  task  of  this  contest  included 
autonomous  exploration  in  an  unstructured  terrain,  as  well  as 
the  localization,  collection  and  assembly  of  different  objects. 

The  next  sections  are  organized  as  follows:  We  first  put 
the  work  in  context  and  give  related  work  (Section  II).  Then, 
the  core  concepts  of  a  RAFCON  state  machine  are  explained 
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(Section  III).  A  formal  definition  of  the  state  machine  is  given 
in  Section  IV.  The  next  Section  V  presents  the  GUI  working 
on  top  of  the  state  machine  core.  More  features  of  RAFCON 
are  listed  in  Section  VI.  An  experimental  validation  is  shown 
in  Section  VII.  Finally,  Section  VIII  concludes  the  paper  and 
gives  an  outlook  on  future  work. 

II.  Related  work 

RAFCON  falls  in  a  broad  category,  which  can  be  named 
robot  programming.  This  field  is  huge  and  includes  Program¬ 
ming  by  Demonstration  utilizing  teleoperation,  kinesthetic 
teaching  or  observational  learning  [5].  Using  these  methods, 
a  robot  can  be  taught  arbitrary  motions.  However,  definitions 
how  to  react  on  certain  inputs,  like  camera  images,  or 
external  events  are  very  limited. 

Another  approach  are  the  aforementioned  symbolic  task 
planners,  for  which  CRAM  [2]  is  an  example.  In  theory, 
those  systems  accept  natural  high-level  commands  such  as 
’’set  the  table  for  breakfast"  and  then  plan  the  involved  steps 
using  a  reasoning  and  prediction  system  with  the  help  of 
detailed  models  and  world  knowledge.  This  is  a  top-down 
approach,  contrasting  the  bottom-up  approach  of  hierarchical 
state  machines. 

Finite  state  machines  (FSM,  or  extensions  of  them)  are 
heavily  used  for  programming  complex  software  or  repre¬ 
senting  extensive  robot  behaviors  [6]— [8] .  Complex  decision 
trees  would  otherwise  be  very  tedious  to  describe  in  huge 
switch  and  if-else  cascades  (“spaghetti  code”).  A  well  known 
kind  of  state  machine  is  the  deterministic  finite  state  machine 
(DFA)  [9].  As  state  machines  do  not  produce  any  output, 
the  finite  state  transducer  (FST)  augments  the  DFA  with  an 
output  alphabet  and  an  output  function  [9]. 

Another  extension  of  FSM  is  statechart,  originally  in¬ 
vented  by  Harel  [10].  Some  of  the  concepts  introduced  by 
Harel  are  orthogonality  (which  is  equal  to  concurrency), 
hierarchy  and  a  special  form  of  broadcast  communication. 

A  further  statechart  dialect  is  SyncCharts  [11].  It  also 
includes  concurrency,  hierarchy  and  information  exchange 
concepts,  yet  in  addition  offering  enhanced  preemption  ca¬ 
pabilities  and  support  for  transition  priorities.  The  clear  focus 
of  SyncCharts  lies  on  reactive  systems,  i.  e.  systems  reacting 
to  external  events.  The  fact  that  there  exists  an  exact  formal 
notation  for  SyncCharts  is  a  clear  advantage  over  statecharts. 

Flowcharts  are  another  type  of  diagram  for  modeling 
behaviors  or  processes.  The  graphical  representation  of  state 
diagrams  like  statechart  and  SyncCharts  share  some  similar¬ 
ities  with  flowcharts.  Yet,  the  formalisms  heavily  differ.  One 
distinction  is  the  way  in  which  a  transitions  is  determined. 
State  diagrams  are  event-driven,  i.  e.  events  trigger  their  cor¬ 
responding  transitions.  For  flowcharts,  transitions  are  either 
automatically  chosen  (if  there  is  only  one)  or  depend  on 
the  outcome  of  a  state  [12],  Strictly  speaking,  flowcharts  are 
not  state  machines,  however  we  include  these  charts  in  our 
broader  sense  of  state  machines. 

For  RAFCON,  we  deliberatively  decided  against  an  event- 
driven  design.  State  diagrams  may  have  advantages  in  reac¬ 
tive  systems  in  which  events  are  in  the  foreground,  such  as 


stopwatches  [10]  or  watchdogs  for  sensor  monitoring  [11], 
However,  with  increasing  complexity,  event-driven  system 
are  error-prone  [13],  resulting  from  complex  topics  that  need 
to  be  tackled,  like  event  caching  and  priorization,  event  expi¬ 
ration  and  parallel  event  handling  [14].  Therefore,  RAFCON 
is  inspired  more  by  flowcharts,  letting  states  decide  about  the 
next  transition  to  follow.  Nevertheless,  this  decision  can  be 
based  on  events,  if  the  state  registered  a  callback. 

In  our  opinion,  statecharts  and  SyncCharts  offer  too  many 
concepts,  which  increase  complexity  and  whose  benefit  is 
arguable.  For  example,  they  allow  transitions  to  cross  hier¬ 
archy  boundaries,  which  is  contrary  to  important  software 
engineering  principles  like  encapsulation  and  composabil- 
ity  [15],  There  are  many  more  concepts  (transition  guards, 
transition  hooks,  deferred  events,  . . . ).  All  of  these  can 
unburden  the  programmer  from  some  work,  while  at  the  same 
time  increasing  complexity  and  with  this  error-proneness  of 
the  underlying  system.  Therefore,  the  RAFCON  core  (see 
Section  III)  is  kept  slim,  with  only  an  essential  feature  set. 

All  state  machine  types  mentioned  so  far  are  general 
concepts  that  are  not  bound  to  robotic  applications.  There 
exist  also  many  solutions  clearly  invented  for  robotic  pur¬ 
poses.  In  [16],  robots  are  programmed  using  generic  action 
components  which  are  mapped  to  statecharts.  Another  state 
machine  like  system  for  representing  robot  tasks  are  skill 
nets  [17],  However,  their  range  of  application  is  rather 
limited,  as  they  lack  concepts  for  hierarchy,  concurrency  and 
explicit  data  handling.  XABSL  [18]  uses  hierarchical  state 
machines  to  define  robotic  behaviors. 

A  proper  tool  for  programming  complex  robotic  tasks  must 
not  only  have  concepts  for  hierarchies  and  concurrencies 
but  also  needs  a  GUI  intuitively  integrating  these  concepts 
and  allowing  for  efficient  programming.  There  is  a  huge 
number  of  visual  programming  tools  for  a  variety  of  different 
domains2.  Worth  mentioning  is  for  example  Scratch,  which 
is  intended  for  education  and  allows  for  both  imperative 
and  event-driven  programming  [19].  The  idea  of  using  a 
visual  state  machine  concept  for  programming  robots  is  not 
new,  either.  One  famous  example  for  programming  LEGO 
Mindstorms  robots  is  NXT-G  [20],  There  are  also  a  lot 
of  hardware-independent  tools,  however  all  of  them  are 
restricted  in  some  way.  Some  are  no  longer  maintained,  like 
ROS  Commander  [8],  RobotFlow  [21]  or  MissionLab  [22], 
others  are  closed  source/commercial,  such  as  Gostai  Stu¬ 
dio  [23],  or  lack  a  graphical  editor,  for  example  SMACH  [3]. 

Further  state  machine  libraries  that  do  not  have  a  graphical 
user  interface  (GUI)  at  all  also  exist,  such  as  Boost  statechart 
[24]  or  Spring  Statemachine  [25]. 

While  all  of  the  mentioned  tools  were  not  considered  as 
sufficient  for  our  needs,  we  adopted  many  or  their  features 
for  RAFCON.  SMACH  for  example  has  a  similar  concept  of 
outcomes  and  data  ports,  called  input/output  keys.  NXT-G 
visualizes  its  input  and  output  data  ports  as  well  as  the 
data  flows,  just  as  RAFCON.  ROS  Commander  includes  a 

2See  http://blog.interfacevision.com/design/design-visual-progarmming- 
languages-snapshots/  for  a  graphical  overview 
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graphical  editor,  however  it  only  offers  a  limited  number  of 
features. 

In  our  opinion,  a  GUI  with  a  graphical  representation  of 
the  state  machine  and  the  option  of  editing,  is  an  important 
supportive  feature  of  a  programming  tool  for  robots.  How¬ 
ever,  this  is  not  an  easy  feature  to  achieve,  as  bigger  state 
machine  with  deep  hierarchies  tend  to  become  very  complex. 
Most  visual  programming  tools  do  not  support  hierarchies, 
like  NXT-G,  or  show  elements  on  different  hierarchy  levels 
in  the  same  size,  such  as  SMACH,  which  does  not  scale. 

The  graphical  representation  of  RAFCON  is  inspired  by 
the  flow  control  tool  Bubbles,  which  has  been  developed  at 
our  institute  some  years  ago  [26]. 

III.  Core  framework 

The  heart  of  the  RAFCON  core  framework  is  a  hierar¬ 
chical  state  machine  whose  components  are  shown  in  the 
class  diagram  in  Fig.  2  and  in  their  usage  in  Fig.  4.  These 
components  are  further  explained  in  the  following  section. 


Fig.  2.  A  class  diagram  of  the  basic  state  machine  classes  of  RAFCON. 

A.  States 

Every  state  machine  must  have  a  single  state  at  its  root, 
the  so  called  root  state.  There  are  three  basic  types  of 
states:  ExecutionState  s.  Hierarchy  State  s  and  two  forms  of 
Concurrency  States. 

When  thinking  of  a  hierarchical  state  machine  as  a  tree, 
then  its  leaves  are  typically  the  ExecutionStates,  see  Fig.  3. 
These  states  cannot  contain  any  child  state  but  instead  each 
of  them  contains  a  Python  script  to  be  run  when  the  state 
is  executed.  This  allows  the  state  to  carry  out  arbitrary 
functions,  like  calling  an  external  robot  API  or  triggering 
a  robot  middle-ware  such  as  ROS. 

HierarchyStates  are  ContainerStates  for  child  states  of 
any  type  and  are  thus  called  parent  states  of  their  child 
states.  The  purpose  of  HierarchyStates  is  simply  to  allow 
for  the  definition  of  hierarchical  structures  by  grouping 
related  states.  The  direct  children  of  a  HierarchyState  can  be 


considered  as  a  flat  state  machine  on  its  own  with  a  single 
entry  state. 

ConcurrencyStates  are  also  ContainerStates.  However,  all 
its  child  states  are  executed  in  parallel.  There  are  two 
subtypes,  PreemptiveConcurrencyState s  and  BarrierConcur- 
recyStates.  If  a  child  state  of  a  PreemptiveConcurrencyState 
finishes,  all  its  sibling  states  (i.e.  states  that  have  the  same 
parent  state)  are  preempted.  In  contrast,  the  BarrierConcur- 
recyState  waits  for  all  of  its  child  states  to  finish  before 
continuing.  ConcurrencyStates  are  crucial  for  applications 
in  which  several  tasks  have  to  be  accomplished  at  the 
same  time.  One  example  is  running  one  or  more  observer 
states  monitoring  the  environment  with  different  perception 
devices,  while  at  the  same  time  an  object  is  manipulated. 

LibraryStates  are  encapsulated  state  machines,  which  can 
be  used  and  treated  as  any  other  state.  This  allows  for 
easy  reusability  and  eases  the  collaboration  on  bigger  state 
machines. 

We  emphasize  that  a  state  in  a  RAFCON  state  machine 
does  not  correspond  to  a  state  of  the  environment  (world 
state)  but  to  a  state  in  the  flow  of  a  robotic  task. 

B.  Outcomes  and  transitions 

Each  state  has  outcomes  that  define  connection  points  for 
transitions.  The  aforementioned  scripts  of  ExecutionStates 
return  a  value  corresponding  to  one  of  the  state’s  outcomes. 
The  successor  state  is  determined  by  following  the  transition 
connected  to  the  returned  outcome.  If  its  target  is  a  sibling 
state,  then  this  state  is  executed  consequently.  Alternatively, 
the  transition  can  be  connected  to  an  outcome  of  the  parental 
ContainerState.  In  this  case,  the  execution  of  the  Container- 
State  is  left  on  the  outcome  the  transition  is  connected  to. 

If  a  HierarchyState  is  to  be  executed,  the  start  transition 
determines  which  of  its  child  states  to  execute  first.  For 
ConcurrencyStates,  no  start  transitions  are  required,  as  all 
inner  states  are  executed  in  parallel. 

Another  core  functionality  of  the  RAFCON  framework 
is  its  integrated  error  and  preemption  handling  (similar  to 
SMACH  [3]).  Every  state  must  have  the  two  outcomes 
aborted  and  preempted.  If  an  uncaught  exception  occurs  in  a 
state,  it  is  automatically  left  on  the  aborted  outcome.  In  Pre- 
emptiveConcurrencyStates,  child  states  being  preempted  due 
to  a  sibling  state  having  finished  its  execution  are  automat¬ 
ically  left  on  the  preempted  outcome.  Based  on  this,  a  pro¬ 
grammer  can  implement  arbitrary  error  recovery  strategies  or 
shutdown  mechanisms  in  states  connected  to  the  appropriate 
outcomes.  In  case  a  triggered  aborted/preempted  outcome 
has  no  transition  connected  to  it,  then  the  aborted/preempted 
outcome  of  the  parent  state  is  triggered.  This  propagation 
is  continued  until  an  outcome  with  a  transition  is  found. 
Thereby,  states  handling  preemption  and  errors  can  be  placed 
at  any  level.  PreemptiveConcurrencyStates  having  caused  a 
preemption  stop  its  propagation.  In  contrast,  errors  propagate 
up  to  the  root  state  and  stop  the  execution,  if  the  error  is  not 
caught. 
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C.  Data  ports  and  data  flows 

RAFCON  supports  concepts  for  private,  scoped  and  global 
variables.  Private  variables  can  be  defined  within  the  script 
of  an  ExecutionState  and  do  not  leave  this  scope.  However, 
states  can  pass  values  to  other  states  using  data  ports  and  data 
flows,  which  relates  to  scoped  variables.  For  this,  every  state 
can  define  input  data  ports  that  correspond  to  parameters 
of  a  function.  Similarly,  a  state  defines  output  data  ports, 
corresponding  to  return  values  of  functions.  Each  data  port 
has  a  name,  data  type  and  default  value.  Values  on  input  data 
ports  are  passed  to  the  script  of  an  ExecutionState.  This  script 
can  then  assign  values  to  the  output  data  ports  of  its  state. 
Finally,  variables  globally  accessible  are  stored  in  the  global 
variable  manager.  This  manager  supports  storing  variables 
by  value  and  by  reference  and  features  thread  safe  read  and 
write  accesses. 

Data  flows  are  directed  and  define  the  mapping  between 
data  ports.  If  a  data  flow  connects  two  data  ports,  then  the 
value  assigned  to  its  source  is  forwarded  to  its  target.  By  this, 
values  cannot  only  be  passed  between  sibling  states,  but  also 
up  and  down  in  the  hierarchy. 

IV.  Formal  state  machine  description 

The  concepts  of  a  RAFCON  state  machine,  described 
in  the  previous  section,  contain  components  distinguishing 
it  from  all  other  state  machines  mentioned  in  Section  II. 
Therefore,  in  the  following,  we  will  give  a  formal  notation 
of  our  state  machine  using  predicate  logic  and  set  theory. 

Concerning  the  execution  semantics,  the  RAFCON  state 
machine  model  resembles  a  FST  with  the  Moore  model  [9], 
as  the  actions  of  the  state  machine  take  place  during  the 
execution  of  a  state  and  not  during  the  transition. 

However,  relating  to  data  handling,  our  state  machine 
approach  is  similar  to  the  Mealy  model  [9].  The  main 
difference  to  the  Mealy  model  is  that  the  input  for  a  state 
is  not  associated  with  the  transitions  but  is  passed  via 
dedicated  data  edges,  called  data  flows.  More  specifically, 
states  forward  their  output  as  input  to  other  states  (lxn 
relation). 

First,  we  define  the  elements  of  a  state  machine  and 
its  relationships.  Then,  the  definition  of  a  RAFCON  state 
machine  is  provided. 


Fig.  3.  The  hierarchical  state  machines  in  RAFCON  can  be  represented 
as  a  tree.  The  root  state,  all  direct  children  of  a  hierarchy  state  (HS),  as 
well  as  each  direct  child  of  a  concurrency  state  (CS)  can  be  considered  as 
a  separate,  flat  state  machine  (dashed  rectangles).  The  leaves  of  the  tree 
are  typically  execution  states  (ES),  but  could  also  be  empty  hierarchy  or 
concurrency  states. 


Definition  1  (State):  A  state  s  is  an  entity  having  an 
execution  mode  and  type:  sern(s)  £  {active,  inactive}, 
type(s)  £  {execution,  hierarchy,  concurrency}.  The  differ¬ 
ent  states  are  called  execution  states,  hierarchy  states  and 
concurrency  states,  respectively. 

Definition  2  (RAFCON  state  machine  tree  ( RST )):  A 
RAFCON  state  machine  tree  (RST)  is  a  rooted  tree 
G  =  ( S,E )  with  r  £  S  being  the  root  vertex.  S  is  the 
set  of  nodes  and  E  is  the  set  of  edges  which  define  the 
tree-order  x  <  y  (fix  £  V  \  r  :  r  <  x),  following  the 
definition  of  [27,  p.  13-15],  All  vertices  s  £  S  are  states, 
therefore  r  is  also  titled  the  root  state.  All  states  s  £  S  with 
type(s)  =  execution  must  be  leaves  of  the  tree.  In  Fig.  3, 
an  example  of  a  RAFCON  state  machine  tree  is  shown. 

Using  the  tree-order  of  a  RST,  we  can  define  further 
relations  on  such  a  tree: 

Definition  3  (parent):  In  a  RST  G  =  ( S,E ),  state  p  £  S 
is  called  a  parent  of  state  s  £  S,  if  p  <  s  and  p  and  s  being 
neighbors  [27,  p.  3]  (i.  e.  share  a  common  edge  e  £  E).  This 
is  written  as  parent  (p,s). 

Definition  4  (children):  In  a  RST  G  =  ( S,E ),  the  chil¬ 
dren  of  a  state  p  £  S,  written  as  children(p),  is  defined  as 
the  set  of  all  s  £  S  :  parent  (p,  s ). 

Definition  5  (siblings):  In  a  RST  G  =  ( S,E ),  two  states 
s,s'  £  S  are  said  to  be  siblings,  write  siblings(s,  s'),  if 
3 p  £  S  :  parent(p,  s)  A  parent(p,  s').  Note  that  s  and  s'  can 
be  the  same  state. 

The  following  definitions  6  and  7  are  related  to  the  logical 
flow  of  a  RAFCON  state  machine. 

Definition  6  (Logical  port):  A  logical  port  is  a  couple 
l  =  ( s,t )  with  state  s  and  type  t  £  {income,  outcome}, 
outcome  £  {aborted,  preempted,  common}.  A  logical  port 
with  any  type  of  outcome  is  literally  called  an  outcome. 

Definition  7  (Transition):  A  transition  is  a  couple  t  = 
(h,h)  with  l\  =  (si, outcome),  1-2  =  (S2,  income)  both 
being  logical  ports  and  siblings(si,  S2).  h  is  called  the 
source  port,  l2  the  target  port. 

The  following  definitions  8  through  11  are  related  to  the 
data  handling  of  a  RAFCON  state  machine. 

Definition  8  (Data  port):  A  data  port  is  a  triple  d  = 
(s,  t,  v )  with  state  s,  type  t  £  {input,  output}  and  default 
value  v  £  A,  whereat  A  is  an  arbitrary  alphabet. 

Definition  9  (Data  flow):  A  data  flow  is  a  couple  F  = 
(di,d2)  with  di  =  (si,ti,vi)  and  d2  =  {s2,t2,v2)  both 
being  data  ports,  which  must  fulfill 

(siblings ( s  1,  s2)  A  1 1  =  output  A  t2  =  input)  V 
(parent(si,  S2)  A  t\  =  t2  =  input)  V 

(parent(s2, Si)  f\t\=t2  =  output) 

Thus,  a  data  flow  exists  either  between  two  sibling  states 
or  between  a  child  and  its  parent  state. 

Definition  10  (Data  port  value):  Each  data  port  d  = 
(s,  t,  v )  has  a  value  a  of  a  certain  alphabet  A:  value((i)  =  a. 
By  default,  value(d)  =  v.  If  t  =  output  and  type(s)  = 
execution,  then  the  output  function  pe  can  determine  this 
value  (see  Definition  12).  If  there  is  a  data  flow  /  =  (d',d), 
then  the  value  of  the  source  port  d'  defines  the  value  of  the 
target  port  d:  (value((f)  =  a')  =>  (value(d)  =  a'). 
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Definition  11  (Value  vector):  A  value  vector  Vs>tt'  with 
state  s'  and  data  port  type  t'  £  {input,  output}  is  a  vector 
consisting  of  all  values  assigned  to  all  ports  of  that  type  at 
that  state,  thus  [value(di),  valued),  •  •  •]  for  all  d*  =  (s  = 
s',t  = 

With  the  definitions  of  the  elements  of  a  state  machine 
and  its  relations,  the  state  machine  definition  can  be  given: 

Definition  12  (HFPD):  A  hierarchical,  parallel,  finite 
state  machine  with  data  flows  (HPFD)  is  a  11-tuple 
(S,  W,  G,  L,  T ,  D,  F.  M,  Sex it,  Texit,  P),  where 

•  E  is  the  data  alphabet.  This  is  typically  R,  but  can  also 
contain  e.  g.  strings  or  lists. 

•  W(t)  :  t  i — /  E n,n  £  N  is  a  vector  function 
representing  the  world  state  at  time  instance  r.  This 
vector  function  serves  as  access  to  global  variables,  see 
Section  III,  or  sensor  readings.  In  robotic  contexts,  E  is 
not  finite  and  thus  neither  are  the  elements  of  W(t). 

•  G  =  (S,  E)  is  a  RST,  with  the  set  of  states  S  being 
finite  and  non-empty. 

•  L  is  the  set  of  logical  ports,  whereat  Ms  £  S  :  (3!Z  £  L  : 
l  =  (s,  income))  A  (3!T  £  L  :  l’  =  (s,  aborted))  A  (3\l"  : 
l"  =  (s,  preempted)).  Thus,  all  states  must  have  exactly 
one  logical  of  each  type  income,  aborted  and  preempted. 
Furthermore,  V/  =  (s,t)  £  L  :  s  £  S. 

•  T  is  the  set  of  transitions,  with  Vf  =  (Zi,  I2)  £  T  :  l\  £ 
LAl2  £  L. 

•  D  is  the  set  of  data  ports,  with  fid  =  (s,t,v)  £  D  :  s  £ 
S  Are  E. 

•  F  is  the  set  of  data  flows,  with  fif  =  ( d\,d2 )  £  F  : 
d\ ,  d2  £  D. 

•  M  is  the  set  of  all  output  functions  pe  :  Uejnput  x 
W(t)  i-a  Te, outcome  x  Ve, output  for  the  execution  states 
e  £  S.  Here,  V}, input  and  He, output  are  the  input  respec¬ 
tively  output  value  vectors  of  e  and  Pe, outcome  being  the 
set  of  all  logical  ports  l  =  (s  =  e,t  =  outcome)  £  L. 
The  output  functions  have  access  to  the  current  world 
state  W(t).  Together  with  the  input  port  values,  they 
determine  the  outcome  port  and  the  values  assigned  to 
the  output  ports.  The  evaluation  of  an  output  function 
takes  a  certain  amount  of  time  At  >  0. 

•  Gentry  C  S'  is  the  set  of  all  start  states.  A  start  state  is 
the  state  evaluated  first  when  entering  a  hierarchy  state. 
Thus,  for  each  hierarchy  state  h  £  S,  there  is  at  most 
one  state  s  £  Sentry  with  parent (h,  s). 

•  Tex it  is  a  set  of  couples  £exit  =  (li,l2)  with  l\  = 
(si,ti  =  outcome)  £  L  being  the  source  outcome, 
l2  =  (s2,t2  =  outcome)  £  L  being  the  target  outcome 
and  parent (S2,  Si).  If  the  execution  (see  further  down) 
reaches  an  outcome  being  the  source  port  of  a  couple 
fexit  G  Texit,  then  the  state  s2  of  the  target  outcome  is 
left  at  this  target  outcome  l2. 

•  P  is  the  set  of  all  outcome  functions  pc  : 
J3(T'chi Mren ( e),  outcome)  1  t  Tc  outcome  for  the  concurrency 
states  c  £  S.  Here,  P(Tchildren(c)>  outcome)  is  the  power 
set  of  all  outcomes  of  all  children(c)  and  Tc, outcome  is 
the  set  of  all  logical  ports  l  =  (s  =  c,t  =  outcome)  £ 
L.  If  one  child  state  of  c  exits  (c  being  a  preemptive 


concurrency  state)  or  all  children  of  c  have  exited  (c 
being  a  barrier  concurrency  state),  then  pc  determines 
the  outcome  of  c  on  which  c  is  exited. 

The  following  properties  apply  for  HPFDs: 

•  If  a  hierarchy  state  is  executed,  then  the  execution 
directly  starts  with  the  entry  state  defined  by  ,S'cn,ry 
and  finishes  when  an  exit  outcome  defined  by  Tex;t  is 
reached. 

•  If  a  concurrency  state  is  entered,  all  of  its  children  are 
entered  in  parallel.  Thus,  the  execution  splits  up.  The 
outcome  function  p,  defines  on  which  outcome  to  leave 
the  concurrency  state. 

•  Initially,  all  states  are  inactive:  fis  £  S,  sem(s)  = 
inactive.  When  a  state  s  is  entered,  meaning  that  the 
execution  reaches  an  income  l  =  (s,  income)  £  L, 
then  sem(s)  =  active.  Accordingly,  when  a  state  is 
left,  meaning  that  the  execution  reaches  an  outcome 
l  =  (s,  outcome)  £  L,  then  sem(s)  =  inactive. 

•  Every  port  l  =  (s,t  =  outcome)  £  L  can  only  be  the 
source  of  either  one  t  £  T  or  one  fexit  £  Tex it. 

•  Transitions  are  only  allowed  in  hierarchy  states. 

With  these  definitions,  for  example  deadlock  detection 

and  reachability  analysis  are  possible  in  future  work.  Fur¬ 
thermore,  it  enables  comparisons  with  other  state  machine 
approaches. 

V.  Graphical  user  interface 

The  GUI  is  an  important  feature  of  RAFCON.  A  screen- 
shot  of  it  with  an  example  state  machine  is  shown  in  Fig.  5. 
The  user  interface  distinguishes  RAFCON  from  other  flow- 
control  tools,  especially  with  its  central  element,  the  graphi¬ 
cal  state  machine  editor.  Using  this  GUI,  state  machines  and 
their  execution  status  can  be  viewed  and  observed.  On  top  of 
that,  state  machines  can  be  created  from  scratch  and  edited, 
even  during  the  execution  of  a  state  machine. 

The  GUI  allows  for  visual  programming.  Compared  to 
textual  programming,  most  of  the  work  can  be  accomplished 
straightforward  using  only  the  mouse;  code  is  replaced  by  a 
compact  graphical  representation.  This  helps  in  creating  a 
mental  model  of  a  state  machine  [28].  Both  logical  and  data 
connections  can  be  seen  on  the  first  sight.  In  addition,  the 
current  execution  point(s)  are  highlighted.  Programming  state 
machines  visually  is  fast  and  getting  started  is  easy,  as  the 
interaction  is  intuitive.  This  is  supported  by  the  layout  and 
design  of  the  GUI,  which  was  developed  in  cooperation  with 
a  professional  interface  designers3.  A  video  showing  how  to 
program  tasks  in  RAFCON  is  provided  next  to  this  paper. 

A.  GUI  layout 

The  GUI  is  implemented  with  the  GTK+  widget  toolkit. 
It  is  completely  separated  from  the  RAFCON  core.  Changes 
made  to  the  core  are  published  using  the  observer  pattern  to 
the  model-view-controller  architecture  (MVC)  of  the  GUI. 
The  layout  and  design  of  the  GUI  follow  commonly  ac¬ 
cepted  principles.  One  example  for  this  is  the  arrangement 

Tnteraktionswerk,  https://interaktionswerk.de/ 
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Fig.  4.  Screenshot  of  the  RAFCON  GUI,  showing  an  example  of  a  simple  state  machine  for  a  robotic  task.  The  robot  explores  the  environment  until  a 
red  ball  is  detected  or  the  time  runs  out. 


and  alignment  of  elements  following  the  gestalt  principles 
proximity,  similarity,  continuity  and  closure,  which  improves 
the  effectiveness  of  information  retrieval  [29]. 

Flexibility  and  modularity  are  further  characteristics  of 
the  GUI.  The  aforementioned  graphical  editor  is  the  central 
element  of  the  GUI  (see  V-B)  and  typically  takes  the  most 
space.  It  is  surrounded  by  three  sidebars.  The  scalable, 
detachable  and  foldable  sidebars  are  organized  in  notebooks, 
whose  tabs  can  be  reordered. 

The  right  sidebar  is  named  the  state  editor ,  see  (1)  in 
Fig.  4.  The  selected  state  is  shown  in  here  with  all  its  details. 
Common  state  properties  such  as  name  and  description  can 
be  changed.  In  addition,  there  are  several  widgets  to  modify 
outcomes,  input/output  data  ports,  scoped  variables  (a  feature 
to  graphically  ease  connecting  input  and  output  ports  of 
sibling  states),  transitions  and  data  flows.  For  execution 
states,  a  source  code  editor  allows  for  altering  the  code  with 
code  highlighting  and  syntax  check. 

The  left  sidebar  is  composed  of  several  widgets  with  more 
state  machine  related  content: 

(2)  Library  manager :  shows  all  available  libraries,  which 
can  be  added  to  the  current  state  machine  using  drag 
and  drop 

(3)  State  machine  tree:  gives  another  tree  perspective  on  a 
state  machine  and  allows  for  navigation 

(4)  Global  variable  manager:  shows  the  value  of  all  global 
variables 

(5)  Modification  history:  allows  to  undo  and  redo  changes 
made  to  the  state  machine.  The  modifications  history 
is  stored  as  a  tree.  The  widget  allows  to  access  the 
different  branches  of  the  history. 

(6)  Execution  history:  lists  the  executed  states  in  chrono¬ 


logical  order  and  optionally  shows  the  context  data 

The  sidebar  at  the  bottom  only  consists  of  a  logger  (7).  All 
log  entries,  from  the  core,  the  GUI  and  the  executed  states 
are  shown  here.  The  messages  are  color  coded  and  can  be 
filtered  by  log  level. 

B.  Graphical  editor 

A  lot  of  effort  has  been  put  into  the  development  of 
the  graphical  state  machine  editor,  see  (8)  in  Fig.  4.  The 
biggest  challenge  here  is  the  proper  visualization  of  huge 
state  machines  with  deep  hierarchies,  as  mentioned  in  II.  A 
user  should  be  able  to  quickly  understand  the  purpose  of  a 
state  machine  and  easily  navigate  both  within  one  hierarchy 
level  and  up  and  down  the  hierarchy. 

For  this,  a  panning  and  zooming  mechanism  was  intro¬ 
duced.  Elements  down  in  the  hierarchy  are  smaller  than 
further  up  in  the  hierarchy.  Details  disappear  when  they  get 
too  small.  This  intuitive  approach,  common  in  digital  maps, 
helps  in  navigating  even  complex  state  machines  easily. 

Fully  zoomed  out,  the  user  only  compactly  sees  the 
highest-level  states  and  their  connections.  Therefore,  it  is 
easy  to  grasp  the  coarse  task  flow,  as  one  is  not  distracted  by 
the  details  of  the  implementations  of  the  single  steps  within 
a  task.  If  one  is  interested  in  the  composition  of  a  state, 
the  mouse  cursor  can  be  moved  over  the  state  and  the  scroll 
wheel  turned.  Consequently,  the  state  is  zoomed  in  and  more 
details  of  its  inner  content  (child  states,  transitions,  etc.)  are 
revealed. 

Further  interaction  like  moving  or  resizing  states,  adding 
connections  with  via-points  is  possible  as  well.  The  control 
of  these  actions  is  similar  to  that  of  other  applications,  such 
as  UML  editors. 
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There  are  different  viewing  modes  implemented,  which 
can  be  activated  and  allow  to  further  focus  on  currently 
relevant  aspects  of  a  state  machine.  By  default,  everything  is 
shown.  Other  view  modes  hide  all  data  flow  related  entities 
or  put  everything  in  the  background,  except  the  currently 
selected  state  with  its  connections. 

If  a  state  is  selected,  it  is  marked  with  a  blue  border  and 
its  details  are  shown  in  the  states  editor.  There  it  can  further 
be  inspected  and  manipulated. 

VI.  Further  features 

Not  all  of  the  features  of  RAFCON  have  been  described 
yet.  While  it  is  not  possible  to  mention  all  in  the  scope  of 
this  paper,  at  least  the  most  important  remaining  ones  shall 
be  listed  here. 

RAFCON  stores  state  machines  in  a  human  readable  file 
format.  Each  state  is  stored  in  its  own  folder  on  the  file 
system,  containing  separate  JSON  files  for  core  and  GUI 
data.  The  folder  structure  directly  reflects  the  state  machine 
tree.  This  enables  versioning  of  state  machines  in  repositories 
and  thus  collaborative  state  machine  programming. 

The  comprehensive  core  API  allows  for  programmatic 
state  machine  generation  from  within  another  tool,  e.  g.  task 
planners  like  CRAM. 

Modifications  of  the  state  machine  can  be  conducted 
during  runtime.  The  script  code  of  ExecutionStates  can  be 
changed  as  well  as  the  stmcture  of  the  state  machine. 

Using  the  stepping  mode  of  the  execution  engine,  a  state 
machine  can  easily  be  debugged.  Similar  to  the  debug  mode 
in  modern  IDEs,  one  can  step  over,  into  and  out.  Hereby, 
values  assigned  to  data  ports  are  shown  in  the  GUI. 

On  top  of  that,  one  can  also  step  backwards,  due  to 
the  execution  history  being  stored  including  the  whole  data 
context.  To  the  best  of  our  knowledge,  this  feature  is  novel 
in  the  context  of  debugging  capabilities  of  IDEs  or  visual 
programming  tools.  For  ExecutionStates,  instead  of  the  nor¬ 
mal  script,  an  optionally  defined  backwards -execution  script 
is  executed.  This  helps  debugging  complex  state  machines 
as  it  eases  the  way  to  return  to  a  certain  execution  point. 

Finally,  the  state  machine  can  be  started  at  an  arbitrary 
state,  which  can  be  programmatically  specified  by  its  unique 
state  path  or  graphically  selected  by  the  user. 

During  development,  the  RAFCON  GUI  is  essential  for 
programming  state  machines  (see  chapter  V).  When  the  state 
machine  is  ready  for  release,  the  RAFCON  core  can  execute 
the  state  machine  on  the  target  device  without  any  GUI 
overhead.  This  makes  our  framework  very  lightweight.  Yet, 
the  GUI  allows  the  remote  control  of  state  machines  running 
on  another  host. 

VII.  Case  studies 

RAFCON  is  a  software  tool  which  aims  at  offering  an 
intuitive  way  to  program  robots  and  helps  to  build  a  clear 
hierarchical  system  architecture.  However,  it  is  difficult  to 
give  a  statistical  evaluation  of  its  usability  and  intuitiveness 
or  quality  measurements  of  systems  designed  with  our  tool. 


Fig.  5.  A  coarse  overview  of  the  role  of  RAFCON,  orchestrating  the 
different  system  components  in  the  SpaceBotCamp  competition. 

Thus,  we  focus  on  demonstrating  successful  applications  of 
our  software  in  challenging  scenarios. 

In  the  SpaceBotCamp  Competition  held  in  November 
2015  and  organized  by  the  DLR  Space  Administration,  we 
participated  together  with  nine  other  teams.  The  mission  was 
to  explore  a  previously  unknown,  moon  like  environment 
with  a  mobile  robot  (see  Fig.  1),  find  two  objects  and  finally 
bring  them  to  a  base  station  for  assembly.  A  time  limit  of 
sixty  minutes  had  to  be  met  and  the  communication  to  the 
robot  was  delayed  by  four  seconds  round  trip  time.  Thus  a 
very  high  level  of  autonomy  was  necessary  [30]. 

Our  team  was  the  only  one  to  fulfil  all  tasks  of  the 
competition  specification.  Furthermore  we  accomplished  the 
mission  fully  autonomously,  requiring  only  half  of  the  given 
time  limit.  Next  to  a  robust  hardware  design  and  sophisti¬ 
cated  solutions  for  navigation,  manipulation  and  computer 
vision,  our  RAFCON  state  machine  concept  played  a  vital 
role  in  orchestrating  all  system  components  (for  the  coarse 
architecture,  see  Fig.  5). 

Our  final  state  machine  had  a  complexity  of  more  than  700 
states,  more  than  1200  transitions  and  eight  hierarchy  levels. 
This  is  a  high  number,  considering  that  the  states  are  only 
performing  high  level  actions  (like  retrieving  some  knowl¬ 
edge  of  a  world  model  or  driving  the  robot  autonomously  to 
another  viapoint). 

RAFCON  helped  us  to  apply  the  divide  an  conquer 
concept  to  the  task.  This  enabled  several  developers  to 
program  the  state  machine  at  the  same  time.  Specifically, 
states  concerning  navigation,  exploration,  computer  vision, 
object  detection,  world  model  integration,  manipulation  and 
grasping,  were  all  created  independently.  Beyond  that,  the 
initial  strategy  for  solving  the  challenge  could  be  mapped 
out  before  implementing  the  actual  functionalities.  Moreover, 
having  wrapped  all  system  functionalities  into  states,  altering 
the  behavior  of  our  robot  using  the  GUI  was  much  simpler 
compared  to  purely  textual  based  state  machine  descriptions. 

RACELab  is  another  project  at  our  institute,  in  which 
advanced  robot  skills  for  industrial  automation  are  devel¬ 
oped  [31],  These  skills  fully  rely  on  RAFCON  and  demon¬ 
strate  its  usefulness  in  industrial  contexts  with  robot  arms. 
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SAPHARI4  is  a  further  project  example,  in  which  the 
use  of  RAFCON  proved  to  be  fruitful  for  human-robot- 
interaction. 

VIII.  Conclusions 

We  presented  RAFCON,  a  graphical  tool  to  facilitate 
collaborative  programming  of  complex  robotic  tasks.  Hi¬ 
erarchical  state  machines  allow  the  creation  of  concurrent 
flow  controls.  The  intuitive  GUI  and  many  features  like 
the  debug  mechanisms  of  the  execution  engine  extend  its 
usefulness.  This  was  proved  especially  in  the  SpaceBotCamp 
competition,  in  which  our  robot  controlled  by  RAFCON 
fulfilled  the  challenging  mission  of  autonomous  exploration 
as  well  as  object  detection,  collection  and  assembly. 

RAFCON  is  constantly  being  extended  and  improved.  To 
increase  the  usability  and  overview  while  facing  complex 
state  machines,  the  GUI  is  further  enhanced  to  match  the 
design  guidelines  of  our  designer.  One  extension  of  the 
GUI  will  be  a  miniature  view  of  the  state  machine,  which 
could  serve  as  a  time  saving  navigation  alternative.  Another 
planned  feature  useful  for  both  multi-robot  and  mobile  robot 
scenarios  is  the  ability  to  remotely  edit  state  machines. 

We  noticed  the  deficiency  of  a  properly  designed,  well 
supported  and  powerful  task  programming  tool  freely  avail¬ 
able.  Therefore,  we  plan  to  provide  RAFCON  as  an  open 
source  tool  to  the  community5. 
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